「ALB 502 エラーの原因切り分け Yes/No 診断」を作ってみた

[結果A] バックエンドのWebサーバー内部から 500 系エラーレスポンスが返されています。

CloudWatch メトリクスの「HTTP 5XXs(HTTPCode_Target_5XX_Count)」はバックエンドのWebサーバー内部から 500 系のエラー応答コードが返されたことを示しているため、明確にバックエンド側の問題であると言えます。 Application Load Balancer の CloudWatch メトリクス からの引用：

HTTPCode_Target_5XX_Count
ターゲットによって生成された HTTP 応答コードの数。これには、ロードバランサーによって生成される応答コードは含まれません。

バックエンドサーバー側の原因調査は AWS の責任共有モデルによりユーザー側の責任範囲となるため、バックエンドサーバー内部のWebアクセスログやアプリケーションログを調査して、500 エラーが発生した根本原因を特定しましょう。 責任共有モデル

[結果B] ALB とバックエンドWebサーバーのタイムアウト値が関連している可能性があります。

ALB が 502 エラーを返すケースでよく見られる要因の1つとして、バックエンド Webサーバー側の KeepAlive 設定が無効になっている、もしくは KeepAliveTimeout 値が ALB 側のアイドルタイムアウトよりも小さく設定されている場合があります。下記のリンクを参考にこの設定を見直してみましょう。 Apache または NGINX を ELB のバックエンドサーバーとして使用する ※タイムアウトの適正な値はユーザー側のアプリケーション要件等により異なるため、ドキュメント通りに設定すれば必ず 502 エラーが解消するとは限りません。環境に合わせてチューニングする必要があります。

[結果C] バックエンドWebサーバー内部の問題が起因している可能性があります。

ALB の基盤障害が日常的に発生するとは考えにくいため、502 エラーが頻繁に発生している場合はバックエンド側の問題が疑われます。
「バックエンドWebサーバー側から 500 系エラーが返されていないのに、なぜバックエンド側の問題なの？」と疑問に思われるかもしれませんが、例えばバックエンドサーバー内部で処理がスタックして何も応答コードが返されなかった場合に、ALB 側から 502 や 504 のエラーを返すケースがあります。詳しい確認方法は下記のブログ記事でご紹介しているので、参考にしてみてください。 ALB のメトリクス “ELB 5XXs” は、ロードバランサー側の不具合を示していますか？
この場合の調査は AWS の責任共有モデルでユーザー側の責任範囲となるため、サーバー内部のWebアクセスログやアプリケーションログを調査して根本原因を特定しましょう。 責任共有モデル
毎回Webアクセスが増加するタイミングで 502 エラーが出ているような場合は、ミドルウェアのプロセス滞留を疑ったり、必要に応じてバックエンドサーバーのリソース増強なども検討しましょう。

[結果D] ALB の基盤側に問題が発生している可能性があります。

502 エラーが複数のAZで同時に発生しており、かつ「普段は発生しないのに、ある時一度だけ発生した」という状況であれば、ALB 基盤側に問題が発生していた可能性も考えられます。AWS Health Dashboard を確認して、該当する時間帯やリージョン、リソースに関する障害のイベント情報がないか確認しましょう。 AWS Personal Health Dashboard
「ALB 基盤側の問題が疑われるものの、障害のイベント情報が見つからない」という場合は、詳細調査のために当該時刻の ALB アクセスログを収集して、サポートへ問い合わせてみましょう。 Application Load Balancer のアクセスログ

[結果E] バックエンド EC2 インスタンスの基盤側の問題です。

CloudWatch で「StatusCheckFailed_System」が出ていたり、他のメトリクスに途切れが見られる場合、バックエンド EC2 インスタンスの基盤側の問題が疑われます。
すでに Auto Scaling 等でインスタンスが入れ替えられている場合は問題ありませんが、もし異常のあったインスタンスを継続使用している場合は、当該のインスタンスの stop/start をすることで再発を防ぎましょう。 EC2 インスタンスのステータスチェックが失敗する場合の原因と確認方法

[結果F] バックエンド EC2 インスタンス内部の問題です。

特定の EC2 インスタンスでのみ発生しており、異常なメトリクスも特に出ていない場合、バックエンド EC2 内部の問題が疑われます。
「バックエンドWebサーバー側から 500 系エラーが返されていないのに、なぜバックエンド側の問題なの？」と疑問に思われるかもしれませんが、例えばバックエンドサーバー内部で処理がスタックして何も応答コードが返されなかった場合に、ALB 側から 502 や 504 のエラーを返すケースがあります。詳しい確認方法は下記のブログ記事でご紹介しているので、参考にしてみてください。 ALB のメトリクス “ELB 5XXs” は、ロードバランサー側の不具合を示していますか？
この場合の調査は AWS の責任共有モデルでユーザー側の責任範囲となるため、サーバー内部のWebアクセスログやアプリケーションログを調査して根本原因を特定しましょう。 責任共有モデル
毎回Webアクセスが増加するタイミングで 502 エラーが出ているような場合は、ミドルウェアのプロセス滞留を疑ったり、必要に応じてバックエンドサーバーのリソース増強なども検討しましょう。